系列：30 天打造企業級 PLM｜面向：遷移｜素材：資料遷移專案（來源表名一律匿名化，本篇只講方法論）

問題場景

系統做好了，最難的一步才開始：Agile 裡躺著十幾年的料號、BOM 與變更歷史，要搬進新家。而現實是手上沒有完整的 schema 文件，當年知道細節的人也不在了，只有一個能連的資料庫帳號。這不是寫程式的問題，是考古的問題。Migration 篇分上下兩天，今天講策略與考古方法，明天講匯出工具的工程化。

商業邏輯設計

• 「只搬最後發行版」是商業決策。歷史版本的查閱頻率極低，留在轉唯讀的舊系統即可；遷移範圍每加一項，時程與風險都翻倍。範圍收斂成 Part、BOM、AML、附件，各取最後有效狀態
• 不搬不等於不留。法規與稽核的保存義務由舊系統唯讀封存滿足，遷移的目標是新系統能運作，不是消滅舊系統
• 考古結果要業務拍板。哪些品項類型還在用、哪些是十年前的殭屍分類，工程師只能盤點出「有 37 種類型、各幾筆」，哪些要搬是業務單位的決定。所以盤點報告要翻譯成勾選清單，讓非技術主管能做範圍決策
• 遷移窗口由營運日曆決定：什麼時候可以停機、停多久，通常只有一個週末

技術選型與取捨

架構演進：從 Agile 私有黑箱 Schema 到標準化 Staging 交付介面

Oracle Agile PLM 運行十幾年後，資料庫通常會演變成一個「誰都不敢碰」的龐大黑箱：

1. 高度專屬且缺乏文檔的底層 Schema：Agile 內部充斥著專屬的直立式擴充表（如 SRC_EXT_VALUE）、深層的 Node/Class 階層 ID，以及非標準的 List ID 代碼；
2. 缺乏標準資料導出管道：官方提供的匯出工具往往無法完整還原最後有效版本與 BOM 結構，直接連 DB 寫 SQL 又極易踩中狀態與版本過濾的地雷。

Mini-PLM 團隊採用專用 Staging DB 交付架構配合嚴格的資料考古方法論，在舊庫與新系統之間架設一道標準化緩衝層：

巨量遷移工具還是標準 Loader？目標系統的標準匯入介面（Day 26 的批次匯入）適合十萬筆以下；百萬筆等級要走直寫 Staging 的專用通道，分水嶺是逐筆走業務驗證的成本。

Staging DB 作為交付介面，中間隔一層的價值有三：匯出與匯入解耦（兩邊可獨立重跑）、對帳有明確基準點（Staging 的筆數就是雙方簽收的數字）、資料清洗有落腳處。

[舊 PLM] --匯出工具--> [Staging DB] --匯入通道--> [Mini-PLM]
              ↑ 對帳點 1        ↑ 對帳點 2

核心內容：沒有文件的 schema 怎麼考古

方法論四步，全部不依賴文件。

1. 從 UI 反推資料表

在舊系統畫面上改一個值，然後在資料庫裡找哪張表跟著變（比對 update timestamp 或 trigger log）。一天下來就能畫出畫面區塊對資料表的對照草圖：品項主檔在 SRC_PART、版本在 SRC_REVISION、動態擴充欄位集中在一張直立式的 SRC_EXT_VALUE。UI 是最誠實的文件，使用者看得到的每個欄位，資料庫裡一定有家。

2. 分類清查與筆數統計

對每個品項類型（舊系統叫 subclass）跑筆數統計：37 種類型、其中 9 種佔了 98% 的資料、有 11 種十年沒新增過。這張統計表就是給業務拍板的勾選清單雛形。筆數是最便宜的考古工具，它立刻告訴你哪些角落是主戰場、哪些是遺跡。

3. 欄位抽樣驗證

對照草圖是假設，抽樣是驗證：每張表抽幾十筆，逐欄位問「這一欄存的真的是我以為的東西嗎」。實戰教訓是同名欄位不同語意：同一個欄位在不同品項類型下存不同的東西，A 類型存重量、B 類型被挪用存包裝方式。這種欄位挪用是老系統的常態，只有抽樣抓得到。

4. 與畫面對帳

抽取邏輯寫好後，挑 20 筆代表性資料，SQL 撈出來的值逐欄與舊系統畫面比對。「最新已發行版本」的判定邏輯（狀態欄位加排序規則的組合）就是這樣校準出來的。業務說的「現在有效的版本」和資料庫的狀態欄位不一定是同一件事，定義要先在對帳中收斂，才輪得到寫批次 SQL。

版本快照的核心概念也在此定案：變更單的生效與失效紀錄（change-in / change-out）決定每筆結構在哪一版存在。BOM 與 AML 共用同一套快照規則，因為它們在來源系統裡走同一種變更機制。

踩坑記錄

• 測試資料與殭屍資料：十幾年累積的 TEST-、TEMP- 開頭料號、內容空白的半成品紀錄，要在盤點階段標記排除，別讓它們混進筆數決策
• 「順便把資料洗乾淨」的誘惑。遷移途中發現一堆髒資料，很想順手治理。忍住。遷移的驗收標準是新舊一致，資料治理的標準是資料變好，兩個目標混在一起會讓對帳永遠對不平。先原樣搬、後治理

小結

範圍是商業決策，Staging 是解耦與對帳的支點，考古就是 UI 反推、筆數統計、抽樣、畫面對帳這四步不斷循環。明日 Day 24（下）：匯出工具的工程化——可暫停續跑的批次任務與資料轉換。